During the development of an electronic control unit (ECU) it is often desirable to use software quality assurance (SQA) tools to gather performance metrics on the operation of software running on the ECU. Data gathered by SQA tools has typically been used to look for software problems and to optimize the software architecture, i.e., to perform software performance analysis (SPA). During the development phase, it has also been desirable for a designer to monitor accesses to a calibration table of the ECU to determine what portions of the calibration table are currently being used by the software. This calibration table monitoring has generally been referred to as active point detection (APD).
Both the SPA and APD processes work by monitoring the addresses that a microprocessor of the ECU is accessing, while the software is being executed by the microprocessor. The actual data at those addresses is typically irrelevant, as it is assumed that the system is functioning correctly when these processes are used. In general, APD tools monitor the addresses of the accesses to a calibration table. By examining those addresses, a designer can determine whether the ECU is accessing the right area of the calibration table, for current operating conditions of a particular control algorithm. SPA tools work in a similar fashion in that they capture the addresses of the accesses made by the microprocessor to areas of interest. Using these addresses, the designer can monitor trends on how the software is running. This includes, but is not limited to, how often a code section runs, how often a code section is interrupted, what components of a subroutine are run, etc.
During development, various designers have utilized a logic state analyzer (LSA) to provide non-intrusive visibility into the operation of the software of the ECU, by physically probing and monitoring the external bus signals of the microprocessor. When utilized in this manner, the LSA can be used for both SPA and APD processes. However, using an LSA requires a test connector be implemented on the ECU, which if implemented in a production ECU may be intrusive to the production ECU design. For this reason, the use of an LSA is generally limited to bench work and development ECUs. Further, a LSA cannot be used for single chip processors, as such devices do not have an exposed external bus.
An alternative to using an LSA to acquire SPA and APD data is to ‘instrument the code’, which means adding additional code to the software to collect data. Calibration tuning has frequently utilized instrumented software processes. This is due to the fact that calibration tuning is most effective when the ECU is in the production location. In general, instrumented software processes work equally well for both development and production ECUs. When using instrumented code, subroutines are added to the areas in the code where an access to the calibration table is to occur to monitor calibration accesses. The subroutines then write the location of the calibration table access out to a data acquisition location. This allows the designer to log all access to the calibration table. However, this SPA process typically requires significant software maintenance, consumes CPU throughput, consumes memory resources, is time-intensive to maintain, and adversely affects the performance numbers as the SPA process is also consuming throughput.
An alternate software method for collecting APD data is to use a recalculation method. This method determines where in a calibration table an access took place by data logging the parameters that were used to make the access. The software in an external tool (e.g., a personal computer (PC)) then runs this logged data through the same equation that was used by the ECU to provide a list of addresses that were used to access the calibration table. This process also requires significant bandwidth, to capture every access made to the calibration table, such that most designers limit data acquisition to a subset of data points that can be used to indicate a trend of where the calibration table accesses are occurring. Further, even if the data stream from the ECU is running synchronously with the fastest loop of the ECU, there is a potential for data framing errors. Additionally, during development, the algorithm running in the ECU is required to be synchronized with the algorithm running on the tool. If synchronization is not maintained, the calibration table is optimized using the wrong equations.
What is needed is a technique for performing software performance analysis (SPA) and active point detection (APD) on an electronic control unit (ECU) without requiring the use of a logic analyzer. It would also be desirable if the technique for performing SPA and APD did not require implementation of a test connector on the ECU.